IBIS Macromodel Task Group Meeting date: 30 Apr 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz Todd Westerhoff Doug Burns Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Curtis to take the minutes. A Cut & Paste error was noticed by Arpad and described in an email: - Arpad: GetWave_Exists and Use_Init_Output have identical definitions. - This is on page 185. - Do we need a BIRD to fix it? - Walter: Bob pointed out that it is a typo correction. - The Editorial Committee can handle it. - Arpad: Do we need to tell them what to write? - Walter: We can trust them to fix it. - Michael: There is a "known issues" text file. - It is in the same directory as the 5.1 spec. - We can update the text in that file. - There is no need for a BIRD. - Changes are noted for editorial revision. - Bob: I agree with Michael - I don't agree with Ambrish's proposed change. - Arpad: What is it? (recent reply to Arpad's email) - Michael: Page 177, - "Single value data. The user may assign any value..." - Not sure of Ambrish's objection. - Ambrish: The description is inaccurate. - Who is the "user"? - Michael: Oh, user vs. model maker? - Ambrish: It's not clear. - Bob: It was a cleanup of the complete mess in 5.0. - Radek: It would be good to see it (show the text on the screen). - Arpad: Should we look into this now? - Walter: Let the Editorial Committee handle it. - Arpad: Okay, let's move on. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to submit BIRD 160.1 to the IBIS Open Forum. - done - Arpad to check if BIRD 158 can be incorporated in BIRD 116-118 as a shortcut syntax. - done - Walter to write new BIRD for [Repeater/Retimer Pin] keywords. - in progress ------------- New Discussion: IBIS Interconnect Teleconference update: - Michael: (short summary of the last Teleconference). - Continuing review of EMD. - Five specific issues under discussion. Current BIRD Discussions: - Arpad: Which ones should we look at first? I'm open to suggestions. - Fangyi, Radek, can we get an update on Repeater and Dependency BIRDs? - Walter had asked for the Labels BIRD to be discussed. - Walter: I think we should limit discussions to topics for IBIS 6.0. - Radek: Redriver is the first one to worry about for 6.0. - Fangyi: (summary of the current state of the Redriver BIRD 156) - Approach is specifically for AMI, not legacy IBIS SPICE simulations. - Consensus via email discussions was to restrict the BIRD to AMI for now. - Require [Algorithmic Model] keyword in [Model] section. - Ambrish: That doesn't inform the user that it is only for AMI. - Fangyi: Would it be a statement of intent? - Michael: Illegal to use without AMI (so the parser can flag it). - It is much easier to remove a restriction later than to add one. - Place the AMI only restriction on for now, and we can lift it later. - Fangyi: Agree, would a comment saying AMI is required be sufficient? - Bob/Michael: No, it needs to be something the parser can use. - Fangyi: If we limit the scope to AMI we can merge the two BIRDS. - [Repeater Pin] is required. (from BIRD 131) - Michael: If repeater pin is not AMI, then FAIL. - Walter: There are two pins (Tx/Rx), each must use AMI models. - Ambrish: Wouldn't a separate [Model] type be more elegant. - Radek: Nothing to be gained. - [Repeater Pin] gives you two pins. - Michael: [Repeater Pin] does it, or you could do it at the [Model] level. - For example, introduce a new [Series MOSFET] type model. - Walter: Repeater models of this form are already out there. - Ambrish, if you have your own proposal, draft your own BIRD. - Ambrish: I'm just asking for discussion/clarification. - Michael: Everything done in this proposal is based on re-use of [Model]. - [Repeater Pin] would say: - Treat these 2 pins as a single unit. - They both have to be AMI models (at this time). - Radek: There is no need to restrict them to AMI or "error out." - For legacy applications, use them the way they always have been. - Michael: Analogous to [Driver Schedule] - It ties models together, but they can be used independently. - Radek: It is even simpler. - Ambrish: No, you can't do that. - Radek: Repeater is not applied to legacy sims, but the [Models] can be. - Walter: I'll be working on a write-up for a more fundamental issue. - Repeater flow has fundamental Tx, Rx pairs. - Each pair uses the classic IBIS impulse response calculation. - But how does the EDA tool analyze the whole channel for BER? - Problems could arise for the tool during end to end flow. - Each primary pair (Tx,Rx) uses GetWave() or doesn't. - Could easily end up with hundreds of possible combinations of flow. - Working on a document to simplify and explain it. - Arpad: I'm thinking about the timeline. - Need at least one more revision of this. - Deadline is June, 7, and we need to be in two weeks before that. - Who is taking ARs to do what? - Walter: I'll do a flow document for retimers/redrivers for next meeting. - I'm not concerned with combining the existing BIRDs (editorial task). - Radek: Could we approve and forward them to the Open Form next meeting? - Walter: Reference flow is needed, it's currently unclear. - Fangyi: My BIRD says, "flow is the same as 5.1". - Walter: I know you said that, and I actually understand what you mean. - But, does everyone here understand the subtleties? - I could give an example next week and see what everyone does. - How does Rx communicate with Tx? - Ambrish: What do you mean? - Walter: How do you get the input to the Redriver Tx? - What if one uses Init() and one uses GetWave()? - Arpad: We (5.1) have a flow for each "half" channel. - Walter: Fangyi does describe the flow based on the 5.1 flow. - But, how do we handle various combinations? - I know what to do, but we can't assume everyone will. - Bob: There are undefined terms in the BIRD. - Fangyi: (sharing text of his latest BIRD revision) - Walter: Where do you do GetWave()? - Fangyi: Step 7 in the flow refers back to the 5.1 flow. - Walter: If Tx GetWave() does not exist, convolve stimulus with output of Tx Init(). - What about the Tx of the Redriver? - Fangyi: Step 8. - Don't generate stimulus for Redriver Tx, it comes from Redriver Rx. - Walter: Digital vs. Analog stimulus. - Taking a long channel and breaking it into individual 5.1 channels. - Subtle differences occur. - Things get nasty if Tx uses GetWave() and Rx is Init() only. - Ambrish: No nastier than 5.1. - Walter: No, it's worse if daisy chaining multiple Redrivers. - We should advise not to do Tx GetWave() only with Rx Init() only. - Fangyi: We solved these issues in 5.1. - Ambrish: Walter is just saying it's complicated. - Walter: Fine (if you think everyone understands it). - Arpad: We still have the AR issue. Who does what? - Walter: Fangyi, Rx/Tx [Models] should be referenced in [Repeater Pin]. - Ambrish: Just integrate the two BIRDS (131, 156) into one BIRD. - Walter: Why not just leave that to the Editorial Committee? - Radek: Yes, best to go ahead with two separate BIRDs. - In Walter's, legacy IBIS ignores all this. - Bob: I disagree, we should roll them into one BIRD. - Ambrish: What about differences in flow between Redriver and Retimer? - Fangyi: Walter and I talked about our differences with Retimer. - Our proposal - Stimulus for Tx created by EDA tool sampling Rx output. - Walter: Retimer document will be ready for next week's meeting. - Ambrish: What is the other way to do it? - Walter: The Rx of the Retimer has a CDR. - The Rx generates the follow on stimulus for the Tx. - Ambrish: Oh, Fangyi's doesn't do it that way? - Walter: We may need another specifier for Redriver vs. Retimer. - Arpad: Still have my original question. We need a clear set of ARs. - 1. Walter will write up the Retimer BIRD. - 2. Merge BIRD 131 with BIRD 156? Fangyi, can you do that? - Bob: I think we should combine them so it's complete. - Ambrish: Agree. - Walter: We should maintain 3 separate BIRDS. - The Retimers BIRD changes IBIS sections. - The Redrivers BIRDs only affect AMI. - Arpad: Are BIRDs 131 and 156 likely to get opposite approval votes? - Walter: No, they both will pass. - If they don't, then the Open Forum can still vote down what results. - Why bother with the effort to merge them now? - I won't do it. Fangyi can do it if he wants to spend his time. - Ambrish: They should just be combined. - Radek: Walter is right. - If you combine them, then it will be more difficult to do Retimers. - Leave them separate. - Bob: Then how do you link BIRD 156 to [Repeater Pin] (BIRD 130)? - Radek: The only consequence is ambiguity and extra choice for the user. - Bob: We don't want the ambiguity in IBIS. - We need the explicit ties between the BIRDs. - Ambrish: I have to leave now (just past 4PM). - Walter: I'm not wasting any more time on this discussion. Good bye. - Arpad: Unfortunately, no ARs came out of that final discussion. - We'll have to see how this work falls out in the coming week. - Arpad: If there are no other questions, this is a good stopping point. New ARs: AR: Walter working on clearer flow document for Redrivers. (Was this idea abandoned?) ------------- Next meeting: 7 May 2013 12:00pm PT Next agenda: 1) BIRD 131 and BIRD 156 2) BIRD 154, Leaf Labels in List Parameters 3) Task list item discussions. ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives